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« Procede et dispositif pour finterfagage graphique » 



La pr^sente invention concerns un proced§ ainsi qu'un dispositif pour 
Pinterfagage graphique entre un utilisateur et un systeme informatique. 

Elle trouvera en particulier son application dans le domaine de la 
realisation d'interface graphique pour utilisateur, notamment dans le domaine 
des systemes de reservation par ordinateur. 

D'une fa^on generate, les interfaces utilisateurs ont connu une grande 
evolution depuis Timportant succ§s des r§seaux de large extension et en 
particulier de ('Internet 

Les solutions d'interfasage graphique dans le cadre d'lnternet ont 
permis d'importantes Economies en mattere de d§veloppement. 

Cependant, pour des applications complexes, telles que des 
applications professionnelles de systemes de reservation par ordinateur, les 
interfaces d'utilisateurs bas§es sur ces techniques necessitent le transfert de 
grandes pages volumineuses dans un format de balisage du type HTML (pour 
Hyper Text Mark-up Language). 

Des inconvenients li§s a ce type de transmission de pages integrates 
forrnees uniquement dans Sa partie ssrveur et transmises au navigateur du 
poste client posent plusieurs problemes. En particulier, la partie client de 
I'interface d'utilisation presente d'importantes limitations structurelies, liSes au 
langage HTML. En outre, compte-tenu du volume des transferts a operer entre 



le serveur et le poste client, ('occupation du r6seau de transmission est forte, ce 
qui implique un temps de r6ponse Sieve pour les clients disposants d'une 
connexion a faible debit. 

II existe un besoin concemant des interfaces utilisateur disposant des 
atouts de richesse, de flexibilite et de performance des traitements operes dans 
la partie serveur tout en assurant une reduction de I'occupation du reseau pour 
fournir I'affichage au client 

La prSsente invention s'inscrit dans le cadre de cette optimisation et 
permet de r6duire d'une part le temps de calcul sur le serveur et d'autre part le 
trafic sur le reseau entre le serveur et le client, ce qui permet de diminuer le 
temps de reponse global de Implication. En outre, le dispositif de invention 
conserve une grande flexibilite car la partie serveur continue de controler le 
traitement des donnees a afficher. Le dispositif permet egalement de modifier et 
de cnSer les modules de visualisation graphique a afficher pour I'utilisateur ainsi 
que de fournir des instructions en ce qui conceme I'affichage au poste client. 

Plus precisement, Pinvention a I'avantage de fournir aux moyens de 
visualisation des informations fusionnfees entre deux sources de donnees. En 
effet, d'une part, le dispositif de I'invention gen6re des objets statiques 
conserves localement au niveau du poste client et permettant une disponibilite 
locale de multiples objets graphiques utilises pour I'affichage. 

D'autre part, les donnees dynamiques correspondant a la demande du 
client sont generees apr§s traitement dans la partie serveur et transmises au 
poste client. Une fusion des donnees dynamiques et statiques est ensuite 
op6ree pour produire la visualisation en particulier sous forme de pages au 
format HTML en utilisant une application de navigation. 

En implementant un equipement speciftque au niveau du poste client, 
on peut g6n6rer localement le modele de visualisation £ exploiter pour 
I'affichage. Cela est oper6 par Passociation de differents elements de 
constructions du module qui seront detailles plus loin dans la description. 

II s'ensuit que les donnfees de construction des modules de 
visualisation ne transitent piuo pen ic ico^ou. un wmuo, is syo^mv ^i^w.i.^..* 
personnalisable selon les exigences locales du poste client (objets graphiques 
sp6cifiques, regies logiques particuliSres a appliquer, donnfees locales 
particulieres a employer...). 
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Cette perso realisation potentielle du poste client n'afFecte pas ses 
constituants d'origine et en particulier le navigateur : on peut en effet g§nerer 
une page au format HTML directement exploitable par le navigateur. 
On notera ggalement que, les modeles de visualisation etant cre6s 3 partir 
5 d'objets de faibles tallies, leur mise a jour ne necess'rte que peu de ressources 
r&seau. 

On reduit ainsi considerablement le volume des donnees a transmettre 
entre la partie serveur et le poste client C'est ainsi que Con beneficie de la 
richesse des standards de langage de balisage (tel HTML) tout en diminuant 
10 considerablement le temps de reponse et les besoins en reseau. 

D'autres buts et avantages apparaTtront au cours de la description qui 
suit d'un mode pref6r§ de realisation de 1'invention qui n'est cependant pas 
limitatif. 

La pr§sente invention concerns un precede pour I'interface graphique 
15 entre un utilisateur et un systeme informatique dans lequel on effectue les 
actions suivantes : 

- entree d'une demande par I'utilisateur au niveau d'un poste client 

- Transmission de la demande £ une partie serveur, 

- Traitement de la demande et generation d'une n&ponse, 
20 - Transmission de la reponse au poste client, 

- Affichage du resultat de la reponse pour I'utilisateur, 
Selon 1'invention : 

- On gen&re une reponse comprenant des donnees d'instruction et 
des donnees d afficher ; 

25 - Au niveau du poste client, on interprete les donnees d'instruction 

determinant un module de visualisation a exploiter ; 

- Au niveau du poste client, on cree ledit module de visualisation 
par association d'elements de construction disponibles 
localement, 

30 * On fusionne les donnees a afficher avec le modele de 

visualisation en vue de i'affichage du resultat de Sa fusion. 
Suivant des possibility avantageuses mais non limitatives : 

- Les elements de construction comprennent une interface de 
description des objets du modele de visualisation, une couche de 
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presentation et des regies logiques a appliquer localement au 
modele de visualisation ; 

- Au niveau du poste client, on associe au modele de visualisation 
cr6e un ressource de langage parmi les ressources de langage 
disponibles localement ; 

- Au niveau du poste client, on peut associer au modele de 
visualisation des filtres de personnalisation d'affichage pour 
modifier le rendu visuel du modele de visualisation par defaut; 

- Les donnees destruction comportent Tindication du type et les 
) elements caracteristiques de construction de modele de 

visualisation £ creer ; 

- On met a jour las donnees disponibles localement au niveau du 
poste client par les etapes suivantes : 

• On g6n6re, au niveau du serveur, un message de stockage 
5 comprenant des donnees destruction de stockage et les donnees 

a stocker, 

• On transmet le message de stockage au poste client, 

• Au niveau du poste client, on interpr^te les donriSes destruction 
pour executer le stockage et on stocke les donnees a stocker 

>o dans une memoire locale. 

- On effectue Taffichage au niveau du poste client par une 
application de navigation, 

- On utilise des donn§es £ afficher et des Elements de construction 
des modules de visualisation au format XML 

25 - On traduit le nSsultat de la fusion au format HTML en vue de 

I'affichage. 

- La reponse de la partie serveur comprend des donnees 
destruction et des donnees & afficher ; 

Linvention est aussi relative a un dispositif deterfasage graphique 
30 entre un utilisateur et un systeme informatique comprenant : 

• Des moyens d'entree d une demande par S'utilisateur au niveau 
d'un poste client, 



• Des moyens de communication entre le poste client et line partie 
serveur, 

• Des moyens de traitement dans la partie serveur pour la 
generation d'une rdponse, 

s • Des moyens d'affichage du resultat de la rgponse au niveau du 

poste client. 

- II comporte au niveau du poste client un gestionnaire 
destructions apte a interpreter les donnSes ^instruction 
determinant un mod§le de visualisation a exploiter ; 

10 - II comporte un moteur dissociation au niveau du poste client apte 

a crfeer ledit modele de visualisation par association d'elements de 
construction ; 

- II comporte des moyens de stockage des 6!6ments de 
constructions au niveau du poste client ; 

15 -II comporte au niveau du poste client des moyens pour fusionner 

le modele de visualisation et les donnees & afficher, en vue de 
I'affichage du resultat de la fusion. 
A titre prefere : 

- Les elements de construction comprennent une interface de 
20 description des objets du modele de visualisation, une couche de 

presentation et des regies logiques d appliquer localement au 
modele de visualisation ; 

- II comporte un moteur de regies apte a appliquer les regies 
logiques du modele de visualisation ; 

25 - H comporte une application de navigation pour I'affichage du 

resultat de la fusion au niveau du poste client. 
Les dessins ci-joints sont donnes a titre d'exemples et ne sont pas 
limitatifs de I'invention. Us repr6sentent seulement un mode de realisation de 
Tinvention et permettront de la comprendre aisSment. 
30 La figure 1 est une representation schematique du traitement opere 

actuellement entre un client et un serveur iorsqu une requece est foimutee par 
un client en utilisant une architecture basee sur le systeme Internet et Tusage 
d'un navigateur du type Internet Explorer®. 
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La figure 2 presente schSrnatiquement le traitement d'une demande par 
un client avec mise en ceuvre de Tinventioru 

La figure 3 illustre des blocs d'elements constitutors du dispositif de 
I'invention et leur communication. 
5 La figure 4 montre 'etape de fusion de donnees r6alis6es. 

La figure 5 est un exemple de composant integr6 dans les moyens de 
visualisation du poste client. 

On a represents en figure 1 un scenario standard tors de ('utilisation du 
reseau d'extension mondial usuellement denomme « World Wide Web ». Dans 
io ce cadre, les requetes de I'utilisateur au niveau de la partie client correspondent 
a une demande de page au format HTML (Hyper Text Mark-up Language) avec 
les instructions suivantes : http get ou http post 

Une premiere limitation de ce mecanisrne est que I'utilisateur doit 
preciser la fenStre qui va rgaliser I'affichage de (a rSponse et ce avant d'envoyer 
is la requSte. Le serveur ne peut done pas decider d'afficher la reponse dans une 
fenetre de dialogue ou sur la fenetre principale puisque cela a deja et6 defini au 
niveau du client. 

Un autre inconvenient que Ton peut soulever est qu'une seule fenetre 
peut etre rafraTchie d la fois. Par exemple, si la fen§tre principale avait 6t6 

20 divisee en deux sous-fenetres, il est necessaire 3 I'utilisateur d'adresser deux 
requetes successives au serveur pour obtenir le rafraTchissement successif des 
deux sous fenetres. Par ailleurs, les modifications d'affichage se font 
uniquement par rafraTchissement de I'integralite d'une partie de I'ecran alors 
qu'il est possible que la demande du client ne reponde qu'a une simple 

25 demande de mise a jour de certaines donnees. Suivant le dispositif actuel, il est 
cependant necessaire de rafrafchir I'integralite de Pecran pour n'importe quel 
type de modification demandfee. 

II n'y a pas de moyen efficace pour stocker des informations au niveau 
du poste client si ce n'est le recours a des « cookies » (temoins) qui sont 

30 cependant de petite faille et qui n6cessite un transit par le reseau d chaque 
requeld. 

Une fois que i'utilisateur a saisi sa requete celle-ci est transmise par le 
biais du reseau Internet avec le support de protocoles de communication du 
type http (Hyper Text Transfer Protocol). Cette 6tape est representee au rep6re 
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1 a la figure 1. Le traitement de la requete est opere au niveau du serveur et est 
presente au repere 2. Une reponse est ensuite generee comme presentee au 
repere 3, ici sous forme de page au format HTML qui implique la combinaison 
dans une meme reponse des elements de donnees et des elements de 
5 presentation de ce qui doit etre affich6 a I'utilisateur. A chaque fois que Ton 
souhaite acceder a une page, il faut ainsi telecharger depuis la partie serveur 
I'integralite de la page HTML contenant les donnees a afflcher (donnees 
variables et donnees « statiques » de formatage - ex : textes d'aide, couleurs, 
polices de caracteres...). Ainsi le volume des pages transmises sur le reseau 

10 s'avere important. 

Le repere 4 de la figure 1 montre que la reponse sous forme de page 
Web est adressee au client. II faut noter que pour des applications 
professionnelles les donnees doivent etre encryptees ce qui implique un temps 
de traitement et un coOt induit d'autant plus important que le volume des 

15 donnees a crypter est eleve. 

Au niveau du poste client, I'utilisateur peut ensuite disposer de 
I'affichage de la rSponse comme presente au point 5 en figure 1. Cet affichage 
est realise par le biais d'une application de navigation telle que cede disponible 
sous la marque Internet Explorer ®. 

20 Au niveau local, certaines actions peuvent alors avoir lieu pour eviter de 

recourir systematiquement au serveur. Ainsi certaines applications par exemple 
editees en Java Script peuvent etre implementees au niveau du poste client 
pour produire certains outils. Un autre inconvenient des dispositifs actuels est 
done qu'il necessite de recourir a des outils additionnels a programmer au 

25 langage Java Script au niveau du poste client. 

La figure 2 presente au contraire un exemple de scenario de 
fonctionnement cTun dispositif d'interfacage graphique selon I'invention. 

Comme indique pr§cedemment, ('architecture actuelle utiiisee dans le 
cadre du reseau Internet (World Wide Web) pose des problemes dans la 

30 mesure oCi I'integralite de pages au format HTML sont telechargees vers le 
poste client. 

Comme visible en figure 2, tel n'est pas le cas de la presente invention. 
Plus particulierement, lorsque I'utilisateur entre une requete a 
destination de la partie serveur, une demande sous forme d'un message 
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contenant les informations saisies par I'utilisateur est generee au format XML 
(Extensible Mark-up Language) ou sous un autre format structure Dans la 
mesure ou la demande du client ainsi generee reflete Taction de lutiiisateur, 
elle a ete denommee <c evenement » a la reference 1 de la figure 2. 

Apres transmission, cette demande « tenement » est regue et traitee 
au niveau de la partie serveur. La premiere phase du traitement consiste en 
une analyse du contenu de la demande ce qui est fait au niveau d'une couche 
d'interface utilisateur du serveur qui sera presente plus en detail ci-apres. 
Ensuite. on precede au traitement des donnees de la demande « evenement » 
, au niveau d'une couche ^application qui sera egalement presentee plus loin. 

Ces phases sont presentees au repere 2 « traitement » de la figure 2. 
Une fois que la demande a ete traitee, la partie serveur genere la response 
appropriee a I'attention du client Dans ce cadre, au lieu de construire une page 
au format HTML complete, on genere selon Invention une suite ^instructions 
5 qui sera a interpreter par le client Cela donne en particulier une grande 
flexibilite en ce qui concerne le comportement du poste client Par exemple, un 
seul message peut permettre d'operer des operations de rafraTchissement 
d'une partie de I'ecran, d'ouvrir une botte de dialogue, d'afficher une botte de 
message etc. .. et ce de facon simultan§e. 
io Une fois cree, le message est transmis sous forme d'un document XML 

(Extensible Mark-up Language) eventuellement apres compression et cryptage 
en direction du poste client. Cette operation est representee au repere 4 par le 
terme instruction qui correspond a la fonctionnalite decrite au paragraphe 
precedent 

25 Ce message ^instruction est re$u au niveau du poste client et doit etre 

interprets. 

En particulier, les donnfces dynamiques comprises dans la reponse du 
serveur sont recuperees et pourront etre fusionnees avec un modele de 
visualisation qui correspond aux objets statiques necessaires a I'affichage. 
Chaque modele de visualisation est par ailleurs cree, au niveau du poste client, 
pai association d'elements de construction. Ce sont les donnees d'instructicn 
qui determined les elements de construction a associer. La combinaison par 
fusion des deux types de donnees (couche de presentation et donnees 
dynamiques issues du serveur) permet la creation de donnees completes a 
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afficher, en particulier sous forme d'une page au format HTML. On peut dans ce 
cadre utiliser pour la visualisation les fonctionnalites de moyens de navigation 
connus et standard, tels que le navigateur diffuse sous la marque Internet 
Explorer®. 

5 Les avantages de Federation de fusion ainsi realisee dans la partie 

client sont multiples. En premier lieu, une fois que les modeles de visualisation 
et leurs elements de dependance (images, scripts, etc... auxquelsfont appel les 
modeles) ont ete recuperes et sont disponibles au niveau du poste client, 
seules les donnees dynamiques sont a adresser par le biais du reseau de 

10 communication. On abaisse done fortement la consommation du reseau. 

La mise a jour des donnees statiques est de plus tres econome en 
ressources de transmission car il s'agit d'elements de petite dimension. Par 
exemple, si un objet graphique est a changer, il n'est pas necessaire de charger 
tout le module de visualisation qui I'utillse. 

15 En outre, seul le canal de transmission des donnees a besoin d'etre 

securis6 dans les moyens de communication ce qui permet de limiter les 
capacites d'enciyptage necessaires lorsque I'on souhaite securiser les 
communications. 

Une fois que la fusion est operee, son resultat peut etre affiche au 
20 niveau du poste client tel que presente a retape 5 de la figure 2. 

Une interaction locale avec I'utilisateur est ensuite possible tel que 
presents au point 6 et met en ceuvre un moteur de regies apte a appliquer des 
regies logiques associees au modele de visualisation exploite et disponible 
localement, tel que cela sera precise plus loin. Elle peut inclure differents 
25 fonctionnements. 

En particulier, si les instructions transmises par le serveur 
correspondent a des controles (tels un bouton pour I'affichage d'une liste 
deroulante), les tenements a realiser peuvent etre geres par un code au 
format de langage Java Script associe au controle considere. 
30 Si les evenements a operer comportent des interactions entre differents 

conlrdles (par example si le champ A est renseigne, le champ B deviant alors 
obligatoire) on peut operer de differentes facons. 
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Ainsi, si ('interaction est complexe mais rarement utilisee, elle peut £tre 
geree au niveau du serveur et demandee sous forme d'une requete formulee 
par le poste client au poste serveur. 

Si interaction est simple et peut 3tre facilement implementee, eile est 

5 ger6e au niveau du poste client par le moteur de regie local 

Enfin, si aucune des 6ventualites pr§cedentes ne semble opportune, il 
est possible de realiser des courts elements de codage au format Java Script a 
lier £ la page pour realiser une fonctionnalite telle qu'actuellement connue dans 
le domaine des pages HTML utilis6es pour le World Wide Web. 

10 On decrit ci-apr6s plus pr^cisement une structure possible du dispositif 

de Tinvention. Ce dispositif comprend une partie serveur implementee avec des 
moyens Informatiques connus comprenant des moyens de traitement sous 
forme de processeur et des moyens de stockage sous forme de memoire du 
type RAM (Random Access Memory) ou ROM (Read Only Memory). La partie 

15 serveur s'entend d'une seule entite de serveur informatique distant ou de 
plusieurs serveurs connectes entre eux par des moyens de transmission 
usuels. 

Le dispositif comprend egalement une partie implementee localement 
au niveau du poste client pouvant par exemple §tre r§alis§e par un ordinateur 
20 personnel du type PC (Personal Computer), visible en figure 3. 

La partie serveur et le poste client sent relies pour la transmission de 
donnees par le biais de moyens de communication pouvant par exemple etre 
realises par I'intermediaire d'un reseau (R) de large extension (WAN : Wide 
Area Network). 

25 On a represents en figure 3 differents constituents du dispositif de 

Tinvention et leur relation afin de mettre en ceuvre le precede d , interfa9age ici 
decrit. 

Par I'intermediaire du reseau repr6sent§ R f la partie serveur transmet 
une reponse a la demande formulee anterieurement par Tutilisateur, la reponse 
so comprenant des donn§es destructions et des donn6es a afficher. 

On pourra notarnmeni utilise? !e standard XML comms format ds 
langage de balisage. La rSponse est re$ue au niveau d'un gestionnaire 
destructions apte a interpreter les donnees destruction contenues dans la 
r6ponse pour determiner les actions d mener. Dans le cas d'un affichage £ 



11 

realiser, (Interpretation comprend la determination des Elements de 
construction a utiliser pour la generation du modele de visualisation. 

Les resultats de ('interpretation sont transmis a un moteur dissociation 
apte e recuperer les donnees statiques constituant les elements de construction 

5 caracteristiques du module de visualisation precedemment determine. On a 
represents en figure 3 differents elements de construction utilises pour la 
creation du module de visualisation. En particulier, le module de visualisation 
associe une interface de description decrivant les composants de haut niveau 
du modele de visualisation, une couche de presentation rassemblant les 

10 differents elements et attributs lies a une presentation graphique et des regies 
logiques qui correspondent £ la logique locale qui doit etre appliquee au modele 
de visualisation durant son traitement 

A titre prefere, la couche de presentation peut depend re des profils 
d'utilisateur, mais rinterface de description et les regies logiques demeurent 

is identiques. Les elements de construction peuvent par consequent etre des 
donnees totalement independantes et etre stock£s dans des fichiers s£pares ou 
dans un meme fichier selon les besoins. 

D'autres elements sont par ailleurs avantageusement associes aux 
modeies de visualisation ainsi crees. En particulier, des donnees de ressources 

20 de langage sont associees. Ces donnees sont egalement choisies parmi 
differentes ressources disponibles locafement en memoire cache au niveau du 
poste client. On peut ainsi facilement adapter la page a creer a une langue 
predeterminee. [.'indication de la ressource de langage a utiliser est egalement 
presente dans les donnees destructions refues dans la reponse. 

25 On peut aussi associer au modele de visualisation un ou plusieurs 

fittres. Ces filtres completent la personnalisation rendue possible par la 
presente invention. En effet, ils permettent d'adapter Information disponible a 
Tecran e des parametres particuliers au client C'est un moyen particulierement 
efficace de modifier les composants visuels de I'ecran de fa$on non 

30 programmatique, par exemple en ce qui concerne les contrdles utilisateur (ex : 
suppression de certains contrdles de Tecran, modification du caractere 
obligatoire de certains champs de saisie...) 
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Au final, {'association du module de visualisation, du ou des filtres. des 
ressources de langage et des donnees dynamiques regues dans la r§ponse du 
serveur permet de former une page. 

Cette association est presentee plus particulierement & la figure 5. 

5 En revenant a la figure 3, on a represents que la fusion entre les 

donnees statiques ainsi associees et les donnees dynamiques contenues dans 
la r&ponse s' ope re au niveau d'un moyen de fusion. Par le biais de la fusion on 
peut par exemple, creer des donnees au format XML. 

Les applications de navigation standards, en particulier Internet 

10 Explorer ®, exploitent des pages au format HTML. On effectue done avant la 
transmission a Implication de navigation une transformation vers ce format 
HTML par le biais de moyens de transformation. 

Les 6tapes debouchant a la visualisation pour I'utilisateur sont alors 
celles implementees conventionnellement avec les navigateurs existants. 

is Cependant, pour permettre une interaction amelioree avec I'utilisateur sans un 
recours systematique k Pactivite de la partie serveur, le dispositif de I'invention 
comporte §galement un tnoteur de regies apte k exploiter les regies contenues 
dans un rnagasin de donnees. De cette fa$on, on peut gerer des interactions 
simples entre le navigateur et I'utilisateur. Par exemple, on peut determiner 

2D localement les donnees a prevoir dans un menu deroulant suivant le profil du 
client et suivant la saisie precedemment operee par I'utilisateur. On evite ainsi 
un recours systematique a une interrogation du serveur aprfes une saisie du 
client. 

On a egalement represents en figure 3 une possibility de mise h jour ou 
25 d'ajout de donnees dans le rnagasin de donnees. En effet, il peut etre utile de 
rafralchir ou d'augmenter ies donnees contenues localement dans te rnagasin 
de donnfees et servant au moteur de regies. Pour ce faire, on adresse depuis la 
partie serveur jusqu'au poste client une r&ponse contenant des donnees 
destructions et des donnSes & exploiter, ici en vue de leur stockage et non en 
30 vue de I'affichage. 

A reception, {'instruction de stockage est interpreter ce qui res u lie en 
une action de stockage des donnees contenues dans la reponse dans ie 
rnagasin de donn&es. Cette Gtape est Egalement repr6sent6e en figure 3. 
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Par ailleurs, le poste client comporte avantageusement un 6l§ment de 
cache constituant un moyen de stockage de donnees disponible au niveau local 
et dans iequel peut §tre stockee une plurality de donnees comprenant les 
differents Elements de construction. II s'agit done de donnees statiques qui sont 
5 generalement utHisees pour des pages de type HTML. Tout type de memoire 
peut etre utilise pour une telle memoire cache et en particulier une m&moire 
morte de type ROM (Read Only Memory). 

Suivant une premiere possibility les donnees statiques sont installes 
des le depart au niveau du poste client et utilises lorsqu'ils sont demandes pour 
10 etre fusionnes avec des donnees issues du serveur. Ainsi, le serveur n'a pas a 
transmettre les differents elements ou objets utilises pour raffichage. 

II peut 6galement arriver que des elements necessaires a I'affichage 
mals non presents Initialement au niveau du poste client doivent etre utilises. 

Dans ce cadre, la pr&sente invention permet la creation des elements 
15 de construction au niveau de la partie serveur et leur transmission une seule 
fois au poste client pour stockage dans le cache et reutilisation ulterieure. 

On a represents en figure 4 I'etape de fusion operee entre les donndes 
issues du serveur et les donnees issues du cache local apr§s leur association. 

Dans ce cadre, il est represents que la fusion s'effectue dans la partie 
20 du poste client aprds reception des donn&es dynamiques issues du serveur 
dans les instructions constitutes de la reponse du serveur. Le gestionnaire 
destructions, & reception des donnees du serveur, appetle les elements du 
module de visualisation correspondant presents dans !e cache. On les associe 
et on opere la fusion pour la realisation par exemple d'une page a transmettre 
25 aux moyens de visualisation. 

Si un element de construction necessaire n'est pas present initialement 
dans le cache, I'operation decrite precedemment concernant sa transmission 
depuis la partie serveur au poste client est r&alis€e auparavant. 

Avantageusement, on exploite des donn&es au format XML pour la 
30 creation du module de visualisation et pour les donnees & afficher. Une 
traduction au format HTML peut etra operee apres !a fusion par des moyens de 
transformation de fapon £ obtenir un r6sultat sous forme de page HTML 
directement exploitable par une application de navigation conventionnelle. 
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On notera que I'objet de la presente invention assure une grande 
souplesse dans le developpement des interfaces utilisateur graphique tout en 
limitant les volumes des donnees transmises au travers des reseaux. Par 
ailleurs, le poste client reste une structure legere et fakement installee et la 
partie serveur conserve un role primordial dans le traitement des donnees et la 
gestion des elements de visualisation. 
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REVENDICATIONS 

1. Proc6de pour ['interface graphique entre un utilisateur et un systeme 
informatique dans lequei on effectue les actions suivantes : 
5 - entree d'une demande par I'utilisateur au niveau d r un poste client, 

- Transmission de la demande a une partie sen/eur, 

• Traitement de la demande et generation d'une reponse, 

- Transmission de la reponse au poste client, 

* Affichage du r6sultat de la reponse pour I'utilisateur, 
io Caracterise par fe fait que 

- On gen£re une reponse comprenant des donnfees destruction et 
des donnees a afficher ; 

- Au niveau du poste client, on interprfete les donnees destruction 
determinant un module de visualisation d exploiter ; 

is - Au niveau du poste client, on cr£e ledit modele de visualisation 

par association d'elements de construction disponibles 
localement, 

- On fusionne les donnees d afficher avec le module de 
visualisation en vue de I'affichage du resultat de la fusion. 

20 2. Procede selon la revendication 1, 
Caracterise par le fait que 

Les elements de construction comprennent une interface de description 
des objets du modele de visualisation, une couche de presentation et des 
regies logiques a appliquer localement au module de visualisation. 
25 3. Procede selon la revendication 1 ou 2 dans lequei, 
Caracterise par le fait que 

Au niveau du poste client, on associe au modele de visualisation cree 
une ressource de langage parmi les ressources de langage disponibles 
localement ou teiechargeables de la partie sen/eur. 
30 4. Procede selon Tune quelconque des revendications 1 ou 3, 

V/aiaucnac pai ian ^uc 

Au niveau du poste client, on associe au modele de visualisation des 
filtres de personnalisation d'affichage pour modifier le rendu visuel du modele 
de visualisation. 
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5. Procede selon Tune quelconque des revendications 1 a 4 f 
Caracterise par le fait que, 

Les donnees destruction comportent I'indication du type et des elements 
de construction caracteristiques de modele de visualisation a creer. 
6 p ro c6de selon Tune quelconque des revendications 1 a 5, 

Caracterise par le fait que, 

On met a jour les donnees disponibles localement au niveau du poste 
client par les etapes suivantes : 

- On genere, au niveau du serveur, un message de stockage 
comprenant des donnees destruction de stockage et les donnees 
a stocker, 

• On transmet le message de stockage au poste client, 

- Au niveau du poste client, on interprete les donnees destruction 
pour exfecuter le stockage et on stocke les donn§es & stocker 
dans une memoire locale. 

7. Procede selon Tune quelconque des revendications 1 & 6, 

Caracterise par le fait que. 

On effectue I'affichage au niveau du poste client par une application de 
navigation. 

8. Procede selon Tune quelconque des revendications 1 & 7, 

Caracteris6 par ie fait que, 

- On utilise des donnSes a afficher et des elements de construction 
des modfeles de visualisation au format XML 

- On traduit le r6sultat de la fusion au format HTML en vue de 
I'affichage. 

9. Dispositif d'interfa$age graphique entre un utilisateur et un systdme 
informatique, selon Tune quelconque des revendications 1 a 5, comprenant : 

• Des moyens d'entr§e d'une demande par Tutilisateur au niveau 
d'un poste client, 

• Des moyens de communication entre le poste client et une partie 
serveur, 

• Des moyens de traitement dans la partie serveur pour la 
generation d'une r§ponse, 
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• Des moyens d'affichage du resultat de la reponse au niveau du 
poste client 
Caracteris6 par le fait que, 

- La reponse de la partle serveur comprend des donn6es 
5 destruction et des donnees a afficher ; 

- 11 comporte, au niveau du poste client, un gestionnaire 
destructions apte & interpreter les donnees ^instruction 
determinant un modele de visualisation a exploiter ; 

- II comporte un moteur dissociation au niveau du poste client apte 
io a crter ledit modele de visualisation par association dements de 

construction ; 

- II comporte des moyens de stockage des elements de 
construction au niveau du poste client ; 

- II comporte, au niveau du poste client, des moyens pour fusionner 
15 le modele de visualisation et les donnees a afficher, en vue de 

I'affichage du resultat de la fusion. 

10. Dispositif selon la revendication 9, 

Caracteris& par le fait que, 

Les Elements de construction comprennent une interface de description 
20 des objets du modele de visualisation, une couche de presentation et des 
regies logiques d appltquer iocalement au modele de visualisation. 

11. Dispositif selon la revendication 10, 

Caracterise par le fait que 

II comporte un moteur de regies apte A appliquer les regies logiques du 
25 modele de visualisation. 

12. Dispositif selon Tune quelconque des revendications 9 a 1 1 , 

Caracterise par le fait que. 

II comporte une application de navigation pour I'affichage du resultat de 
la fusion au niveau du poste client. 
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ABREGE DESCR1PTIF 
« Proc§d§ et dispositif pour Tinterfagage graphique » 
AMADEUS S.A.S. 

La prfesente invention concerne un procede et un dispositif pour 
I'interfagage graphique entre un utilisateur et un systeme informatique. On 
effectue les actions suivantes : 

- entree d'une demande par I'utilisateur au niveau d'un poste client, 

- Transmission de la demande a une partie serveur, 

- Traitement de la demande et generation d'une r§ponse, 

- Transmission de la reponse au poste client, 

- Affichage du resultat de la reponse pour I'utilisateur, 
Selon Tinvention : 

- On g£nSre une rfeponse comprenant des donnees destruction et 
des donnees a afficher ; 

- Au niveau du poste client, on interprete les donnees destruction 
determinant un module de visualisation a exploiter ; 

- Au niveau du poste client, on cree ledit modele de visualisation 
par association d'elements de construction disponibles 
localement, 

- On fusionne les donnees a afficher avec le modele de 
visualisation en vue de I'affichage du resultat de la fusion. 

Application a la realisation d'interface utilisateur graphique. 
FIGURE 5 
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